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(54) Data structures and method for implementing subcontracts in a distributed object oriented 
system 



(57) Data structures and various methods for invok- 
ing and creating objects are used in a distributed object 
system in order to implement subcontracts. A subcon : 
tract is a selected grouping of basic features or object 
mechanisms that a system provides for use in manag- 
ing objects and has associated functions. A subcontract 
registry is used for creating object references for server 
objects. The subcontract registry has any number of 
subcontract objects within it, and each subcontract 
object may include: a subcontract identifier that identi- 
fies the subcontract object, a quality of service list that 
contains feature name-value pairs, and a create func- 
tion unique to the subcontract object. An implementa- 
tion registry is used for registering any number of 
implementation definitions. Each implementation defini- 
tion defines an implementation for an interface within 
the system, and each implementation definition may 
include: an implementation identifier that identifies the 
implementation, a pointer to a subcontract object con- 
tained in the subcontract registry, an interface identifier 
that identifies the interface being implemented, and a 
set of functions used for creating and invoking a server 
object that are unique to that implementation. One 
method creates an object reference for a distributed 
server object by using the subcontract registry in order 
to identify the unique create function to be used that cor- 
responds to the subcontract functionality desired. 
Another technique invokes a method defined on a 
server object by using an object reference to find the 
appropriate implementation definition in the implemen- 



tation registry. Lookup and dispatch functions unique to 
this definition are used to invoke the method. 
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cation level programmers need-not be aware of the spe- 
cific subcontracts that are being used for particular 
objects. A subcontract associated with an object allows 
the business of implementing an object to be separate 
from the business of implementing the object mecha- 
nisms or features provided by the system. 

One of the reasons that subcontracts are effective 
is because they separate out the business of imple- 
menting objects from implementing object mechanisms. 
The availability of subcontracts enable object imple- 
ment ers to choose from a range of different object 
mechanisms (or features) without requiring that every 
object implementer must become familiar with the 
details of the object implementation machinery. The set 
of features that subcontracts provide are the right levers 
for obtaining control within a distributed environment. By 
design, all of the key actions taken on remote objects 
will involve the object's subcontract in one way or 
another. By way of example, actions such as object cre- 
ation, object reference creation and method invocation 
involve the object's subcontract. Subcontracts provide 
an effective way for plugging in different policies for dif- 
ferent objects and are successful in reducing the func- 
tionality that must be provided by the base system. 

However, conventional distributed object system 
have not utilized the functionality of subcontracts and 
are not well adapted to integrating subcontracts. The 
common object request broker architecture (CORBA), 
defines the notion of an object adaptor. Among other 
tasks, an object adaptor creates servant objects and 
dispatches requests to a server. Object adaptors pro- 
vide a limited set of choices about the server-side object 
mechanisms. However, most object adaptors are sup- 
plied as part of the basic object machinery, and it is not 
realistically possible for application writers to implement 
new object adaptors, or for the object machinery to dis- 
cover and install new object adaptors at run time. For 
example, the Basic Object Adaptor (BOA) defined under 
CORBA is very limited in that it only provides a fixed set 
of features. As discussed above, it is less than desirable 
that an object only be- provided with a fixed set of fea- 
tures. And even if all features are supplied, this comes 
at the expense of performance, and vice-versa. 'How- 
ever, one object in a particular application may only 
need to utilize a limited set of features, as contrasted 
with a different object in the same application that needs 
a different set of features. Thus, prior art object adap- 
tors may unnecessarily burden objects with extra fea- 
tures resulting in high overhead and increased use of 
CPU time. 

Accordingly, the creation of a mechanism that is 
able to implement some of the traditional object adaptor 
functions, while at the same time, being capable of tak- 
ing advantage of the use of subcontracts would be 
desirable. Such an object adaptor would overcome the 
shortcomings of fixed Object Adaptors in that it would 
permit different objects within a distributed system to 
take advantages of some, but not necessarily all of the 



features provided by the distributed object system. 
SUMMARY OF THE INVENTION 

5 Embodiments of the present invention relate to data 

structures for use with subcontracts as well as various 
methods for invoking and creating objects. One data 
structure is a subcontract registry embodied in a com- 
puter-readable medium. The subcontract registry is 

ro used for creating object references forserver objects 
within a distributed object computing system. The dis- 
tributed object computing system may provide a number 
of features (or object mechanisms) for use in the crea- 
tion of object references for server objects. The subcon- 

15 tract registry has any number of subcontract objects 
within it, and each subcontract object contains informa- 
tion relating to a particular subcontract. That information 
may include: a subcontract identifier that identifies the 
subcontract object and a quality of service list that con- 

20 tains feature name-value pairs. The feature name iden- 
tifies one of the features that the particular subcontract 
may provide, and the value may indicate whether ^the 
feature is present or not, or may further qualify the fea- 
ture name. Also included is a create function unique to 

25 the subcontract object. The create function is used to 
create and return an object reference for a server object 
by way of using the features identified by the feature 
names in the quality of service list. 

Another data structure is the implementation regis- 

30 try, also embodied in a computer-readable medium. The 
implementation registry is used for registering any 
number of implementation definitions. Each implemen- 
tation definition defines an implementation for an inter- 
face within a distributed object computing system, and 

35 each implementation definition contains information 
relating to that implementation. That information may 
include: an implementation identifier that identifies the 
implementation, a location indicator to a subcontract 
object contained in the subcontract registry, an interface 

40 identifier that identifies the interface being implemented, 
and a set of functions used for creating and invoking a 
server object that are unique to that implementation. 

One embodiment of the present invention relates to 
a method of creating an object reference for a distrib- 

45 uted server object within the distributed object comput- 
ing system. The method begins by requesting that an 
object reference be created for a server object. Then, a 
subcontract in the subcontract registry is identified that 
corresponds to the server object to be created. This 

so subcontract will have a quality of service list that identi- 
fies the quality of service to be utilized in invoking an 
implementation of the server object. The create function 
of the subcontract is also identified. The create function 
is responsible for creating the server object in a manner 

55 corresponding to the quality of service list. The create 
function is invoked in order to produce an object refer- 
ence for the server object, which is returned to the call- 
ing entity. 
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tations. By way of example, the distributed object may 
be a C++ object that has been provided by an applica- 
tion developer. Alternatively, an implementation for a 
distributed object may be developed within a visual 
application builder 15. This visual application builder 
allows a developer to visually select existing object 
types from a catalog and graphically connect the serv- 
ices provided by one object to the services needed by 
another (attributes, arguments, results etc.) in order to 
create a new implementation for an object. 

An object development facility 16 may be used to 
simplify the creation and the installation of distributed 
objects. It is used to -wrap'' or encapsulate developer 
objects in distributed object code. As such, object devel- 
opment facility 1 6 may be used to transform a developer 
object into an ORB object implementation 14. In this 
example, ORB object implementation 14 is presented 
as a server as shown by its location in the diagram. A 
developer uses an interface definition language to 
define an interface for an ORB object, provides a devel- 
oper object implementation that implements that 
object s behavior, and then uses the object develop- 
ment facility 16 in order to produce an ORB object 
implementation 14. At run time, an instance of this ORB 
object (a servant object) is created that will utilize this 
ORB object implementation 1 4. It should be appreciated 
that the object development facility may also be used to 
create objects that take the role of clients at some point. 

Client 20 communicates with a servant by way of a 
stub 21, a subcontract layer 36, possibly a filter 40, and 
a transport layer 38. Stub 21 includes a surrogate 22, a 
method table 24 and stub functions 25. Client 20 com- 
municates initially with surrogate 22 that appears to the 
client as the servant object. Alternatively, client 20 may 
communicate directly with the servant object through a 
dynamic invocation interface (DM) 26 instead of through 
surrogate 22, method table 24 and stub functions 25. 
Dynamic invocation interface 26 is used to enable cli- 
ents to construct dynamic requests. One procedure by 
which a client may make a call to a servant utilizing the 
above layers is described in more detail below with ref- 
erence to Figure 1b. 

Subcontract layer 36 provides the functionality 
required by an object in order to utilize subcontracts to 
implement various services (or features or object mech- 
anisms) named by a particular subcontract, as 
described in greater detail in above-referenced U.S. 
Patent Application Serial No. 08/554,794, filed 
11/07/95. A subcontract identifies a quality of service 
provided by the distributed object system that may be 
utilized by an individual object. For example, a subcon- 
tract may identify that the feature of security is to be 
used for a particular object. Filter 40. if being used, may 
perform a variety of tasks, such as compression, 
encryption, tracing, or debugging, that are to be applied 
to communications to and from an object. 

Transport layer 38 operates to marshal, unmarshal 
and physically transport information to and from a serv- 



ant that typically does not share the same process as a 
client. 

A standard implementation suite 28 (or object 
adapter) represents a set of subcontracts that interact 
5 with ORB objects 14 in identical ways, as for example 
object key management. One such implementation 
suite is described in the below description of the present 
invention. It should be noted that a subcontract may 
belong to multiple implementation suites. Also, imple- 
10 mentation suites may utilize different -subcontracts. A 
skeleton, that may take the form of either static skeleton 
32 or dynamic skeleton 30. is used to transform 
requests into a format required by a servant object 78 
(as will be explained in more detail below with reference 
is to Figure 1b). Thus, skeletons 30 and 32 call an appro- 
priate servant object 78. Static skeleton 32 is used to 
call interface-specific object implementations 14, while 
dynamic skeleton 30 is used generically when interface- 
specific objects are not available. An ORB interface 34 
20 is the interface that goes directly to the ORB that is the 
same for all ORBs and does not depend upon an 
object's interface or object adapter. 

An ORB daemon 46 is responsible for ensuring that 
object servers are active when invoked by clients. A 
25 technique for starting object servers is disclosed in U.S. 
Patent Application Serial No. 08/408,645 which ,is 
hereby incorporated by reference. 

Secure Protocol 42 is a secure interoperability pro- 
tocol that secures the internet inter-ORB protocol and 
30 helps to transmit information through transport layer 38 
in a secure fashion. This may mean integrity protection, 
confidentiality, etc. The internet inter-ORB protocol is a 
protocol that typically communicates between proc- 
esses on different machines. However, in some cases, 
35 the internet inter-ORB protocol may communicate 
between processes on the same machine. The security 
server 54 is a security administration server that 
secures the services that are used between processes 
on different computers. 
40 Typecode/Any module 44 implements "Typecode" 
and "Any" objects. Typecode describes an Interface 
Definition Language (IDL) data type, allowing type 
descriptions to be transmitted between clients and serv- 
ers. An instance of an IDL data type may be encapsu- 
45 lated by an Any object. An Any object refers to typecode 
of the encapsulated data, and a generic encoding of the 
data. 

An implementation repository 50 is used to store 
information relating to object servers. Specifically. 
so implementation repository 50 stores the information 
needed to start a server process. For example, imple- 
mentation repository 50 stores information such as the 
location of the server program, any arguments to the 
program, and any environment variables to pass to the 

55 program, etc. 

Simple persistence 56 uses an Interface Definition 
Language (IDL)-defined type and the output from run- 
ning that IDL type through the IDL compiler, together 
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with a portion of additional code so that an IDL-defined 
type can be read from, and written to, disk. A naming 
serv.ce 52 is used to name ORB objects. A client may 
use naming service 52 to find a desired object by name 
Naming service 52 returns an object reference, that in s 
turn may be used to send requests to that object An 
Werface Repository 48 (IFR) knows about all interlaces 
for all objects within the distributed object system. 

A request made by a client using a method table 
("m-table") dispatch will pass through a variety of the w 
aforementioned layers of the architecture on its way to 
the servant as diagrammatjcally illustrated in Figure 1b 
The request is initiated by a client and may take any 
suitable form. The form of the request will depend to a 
large extent upon the nature of the programming Ian- is 
guage used to create the client. By way of example if 
the client is written in the C++ language, the request 
may take the form of a C++ method call 62. The call is 
made to a designated object reference taking the form 
of a surrogate. The surrogate includes methods that so 
comply with the object's interface. 

As will be appreciated by those skilled in the art the 
object reference used at different locations within a dis- 
tnbuted object system may vary significantly in appear- 
ance. In the embodiment described, the client side zs 
object reference is a dual pointer (referred to herein as 
a 'fat pointer"). A fat pointer contains two distinct point- 
ers. A first pointer points to a client representation ("cli- 
ent rep") associated with the referenced object A 
second pointer points to a method table of the method 30 
table dispatch 24 that is associated with the referenced 
object. A client representation is an object that has 
methods that support invocation as well as CORBA 
defined -pseudo" object reference operations. These 
operations include, but are not limited to, a "duplicate" 3s 
method, a "release" method, a "narrow" method a- 
hash" method, and an "is equivalent" method. 

After the client has initiated a call, the call is proc- 
essed using a method table dispatch mechanism 24 
Such a technique is disclosed in U.S. Patent Application 40 
Serial No. 08/307.929 and is hereby incorporated by 
reference. - . 

The method table dispatch mechanism uses a 
method table that contains a list of location indicators to 
stub functions 25. one of which is associated with the 45 
method to be invoked. Stub functions 25 receive a func- 
tion or procedure call in the "native" language of the cli- 
ent process, then use either a subcontract layer 36 or a 
native call to eventually call the corresponding servant 
object. The native language may be any suitable Ian- so 
guage. as for example a language such as C++. 

Method table dispatch 24 determines the appropri- 
ate one of the stub functions 25 to process the method 
call, and then pairs the method call with the appropriate 
stub function. In the event that the client making the ss 
method call is in the same process as the servant 
object a local stub function is called. The local stub 
funct.on sends the method call directly to servant object 



78. Alternatively, if the servant object is in a different 

P ™J?ti e 3 remote P roces S- a 'emote stub function is 
called. The remote stub function invokes the client reo- 

th3t th8 inV6Cati0n to ^ 

Subcontracts implemented by subcontract layer 36 
are logic modules that provide control of the basic 
mechanisms of object invocation and argument passing 
that are important in distributed object systems. A sub- 
contract .mplemented by subcontract layer 36 deter- 
mines a specific quality,of service for use by an object 
A subcontract is uniquely identified by a subcontract 
identifier that is typically embedded in an object refer- 
ence. A quality of service is a set of service properties 
Among possible service properties that are selectable 
are qualities relating to server activation, security trans- 
actions, f itterability, and clean shut-down. Subcontracts 
are configured such that certain qualities of service are 
available. With predetermined qualities of service the 
overhead associated with processing individual service 
properties is reduced. Realistically, only "reasonable" or 
commonly used combinations of service properties are 
supported with subcontracts. However, subcontracts 
may be created to meet the specific requirements of a 
given distributed object system. 

The identification of an appropriate subcontract in 
subcontract layer 36 may be thought of as the identif foa-f' 
tion of a desired function that is unique to that subcon- 
tract. For example, a marshal function or an unmarshal 
function is defined for each subcontract. A subcontract 
marshal function is used by a stub to marshal an object 
reference so that it may be transmitted to another 
address space, or domain. The object reference is typi- 
cally processed by a transport mechanism in transport 
layer 38. 

A transport mechanism such as T1 . T2, etc that is 
a part of the transport layer 38 is used to marshal and 
physically transport information to and from servant 
objects. Information, i.e. the object reference or the 
request, is converted into protocols appropriate to a 
given domain. By way of example, protocols may 
include, but are not limited to. Ethernet protocols and 
general inter-ORB protocols (GIOPs). In some uncom- 
mon cases, protocols may even entail the use of elec- 
tronic mail to transmit instructions to be implemented on 
a server. After information is marshaled, the transport 
mechanism then transports information through any 
combination of an operating system, a device driver or 
a network, that are all a part of hardware 70 used by the 
client side of a distributed object system. 

While transport mechanisms require a conversion 
of information into a protocol appropriate to a given 
domain, some transport mechanisms do not require the 
encoding of information for different domains One 
transport mechanism that does not require a conversion 
of information into a protocol appropriate to a domain 
other than the one on which information originates is 
termed a "door". Doors are essentially gateways 
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between two different processes on the same host. The 
use of doors eliminates the" need for a conversion of 
information into a canonical implementation in transport 
layer 38, as there is no need to encode information into 
a protocol that may be used by a different machine by 5 
virtue of the fact that information is remaining on the 
same host and therefore does not require a change of 
domain. Hence, information may simply be "flattened 
out" or marshaled into a stream that is not encoded for 
use by a different machine, and passed between the w 
two processes on the host. 

Once information is transported through hardware 
70 used by the client side, the information is then trans- 
ported to hardware 70 on the server side of a distributed 
object system. Once information is routed through hard- 15 
ware 70, the server side of a distributed object system 
invokes a transport mechanism such as T1 , T2 etc. to 
receive information on an end point that is a part of 
transport layer 38. In the event that an end point is not 
created by transport layer 38, transport layer 38 pro- 20 
vides the functionality needed for the end point to be 
created by subcontract layer 36. By way of example, a 
dedicated end point is typically created by subcontract 
layer 36, while cluster end points, which typically include 
network and TCP/IP end points, are typically created by 25 
transport layer 38. Regardless of whether end points 
are created by subcontract layer 36 or transport layer 
38. end points "live in," i.e. are a part of, transport layer 
38. End points are essentially ports that receive infor- 
mation from a different domain. After an end point in 30 
transport layer 38 receives information transported from 
a different domain, the end point then dispatches the 
information from transport layer 38 to subcontract layer 
36. Subcontract layer 36 then dispatches the informa- 
tion to the skeleton and the servant. 35 

Subcontract layer 36 provides the functionality to 
unmarshal at least some of the information it has 
received. That is, subcontract layer 36 unmarshals at 
least part of the request. Then, the request is dis- 
patched to a skeleton 31 that transforms the request 40 
into an implementation specific format required by serv- 
ant object 78. The skeleton 31 may either be a static 
skeleton 32 or a dynamic skeleton 30 as described 
above. 

In general, a remote request is routed through the 45 
client side and the server side as described above. The 
method call 62 is received, method table dispatch layer 
24 is used to identify an appropriate subcontract prior to 
the selection of a transport mechanism in transport 
layer 38 that marshals the request and prepares it for so 
transport to another domain. Through hardware 70. the 
marshaled request is transported to the server side 
where it is received on an end point that is a part of 
transport layer 38. An appropriate end point receives 
information transported across a wire, and information ss 
is dispatched from transport layer 38 to subcontract 
layer 36, that provides the functionality to at least par- 
tially unmarshal the information it has received. The 



subcontract layer then dispatches the request to skele- 
ton 31 that transforms the request into a specific format 
required by servant object 78. This path is shown by 
arrow 77. and is the path that may be taken by both 
remote and local requests. 

However, if a client and a server are in a local proc- 
ess, i.e. both the client and the server are in the same 
process, the use of the path shown by arrow 77 as 
described above is unnecessarily complex. If it is known 
that the client and the server are in the same process, it 
is possible to shorten the invocation path, or flow path of 
a request for service. If a local process may be identified 
when an object reference is created, shortened flow 
paths, i.e. the paths represented by arrows 75 and 76. 
may be taken to send a request from a client to a server 
that are on the same host. The path represented by 
arrow 76 is more likely to be taken, as it uses subcon- 
tract layer 36 to identify an appropriate subcontract. 
However, in situations in which an appropriate subcon- 
tract does not need to be explicitly identified, the path 
represented by arrow 75 may be taken. 

Figure 5 wiil now be used to describe an embodi- 
ment of an object reference. As will be familiar to those 
skilled in the art, object references may take a variety of 
forms depending upon the location within the process 
that they are being held at any given time. However, £y 
way of background, a representative object reference 
for use in a system that utilizes a low overhead imple- 
mentation suite is illustrated in Figure 5. In the imple- 
mentation shown therein, object reference 150 includes 
a host identifier 152, a port designation 154. and an 
object key 156. Object key 156 includes a subcontract 
identifier 158, a server identifier 160, an implementation 
identifier 162, and a user key 164. Host identifier 152 
denotes a particular computer in a network, while port 
designation 154 identifies the port of the selected com- 
puter that is to be used for communication. Object key 
156 provides further identifying information used in 
order to locate a desired servant object on its host 
machine. 

Server identifier 160 names a particular process or 
program in which the servant object resides, while user 
key 164 is a unique number or string used to locate the 
servant within the process named by server identifier 
1 60. Subcontract identifier 1 58 is used to attach the pro- 
tocol of a particular subcontract and its associated serv- 
ices with a servant, and implementation identifier. 162 
names an implementation of an interface that is to be 
used with that servant object. 

DESCRIPTION OF THE PREFERED EMBODIMENTS 

The present invention relates to an object adaptor 
that is able to interact with and make use of a subset of 
all available features within a distributed object system 
through the use of subcontracts. Such an object adaptor 
need not necessarily supply an exhaustive fixed set of 
all features for alt objects; to the contrary, such an object 
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tion, a Get First function and a Get Next function. The 
Add function may be used to add a new quality of serv- 
ice to the table. In the described embodiment, the Add 
function takes as arguments a Subcontract Identifier 
and a Subcontract Meta Object. A Find function takes 5 
as an argument a Subcontract Identifier and returns the 
Subcontract Meta Object associated with that identifier. 
The functions Get First and Get Next return the appro- 
priate Subcontract Meta Object and are used to iterate 
over the entire table and thus search it completely for a w 
particular quality of service. This subcontract registry 
may be used in the following manner. When a client 
wishes to make a call to a particular server object, the 
subcontract registry may be used to look up the Sub- 
contract Identifier associated with that server object and is 
then to call the appropriate subcontract client represen- 
tation create function in order to create an object refer- 
ence to the particular server object using the 
appropriate features. 

Each object in the system is associated with an 20 
implementation definition. Each implementation defini- 
tion for an object includes such information as the name 
of the implementation, which subcontract to use in cre- 
ating the object, the Interface Identifier for the object , a 
set of call back functions and skeleton information. 25 
These call back functions may be stored in an object. 
Such information for an implementation definition may 
be stored in a wide variety of manners. By way of exam- 
ple, such information may be stored in an implementa- 
tion registry table. 30 

Figure 3 shows an implementation registry 250 in 
accordance with one embodiment of the present inven- 
tion. The implementation registry has entries corre- 
sponding to various implementation definitions. 
Through the use of this table, an implementer of an 35 
object server will be able to provide multiple, different 
implementations of a single ORB object type in the 
same object server. That is, one object type may hake 
various implementations that are identified by distinct 
Implementation Identifiers. Each implementation 40 
defines the behavior for all of the operations and 
attributes of the" interface that it supports. In other 
words, each interface may have many implementations. 
Therefore, each Implementation Identifier represents a 
distinct implementation for an object that uses a partic- 45 
ular subcontract. And each implementation may use a 
different subcontract by way of a subcontract location 
indicator in the implementation registry as will be dis- 
cussed below. In this fashion, the implementation regis- 
try is advantageous in that it allows an invoking function so 
to choose a particular implementation which in turn may 
use a desired subcontract of the subcontract registry. 

Each implementation definition represents an entry 
in the implementation registry that contain location indi- 
cators to the different data stored. The implementation ss 
registry 250 includes an Implementation Identifier col- 
umn 252 that names the implementation, a Subcontract 
Meta Object column 254, an Interface Identifier column 



256, a column 257 for a Ready Flag, a call back func- 
tions column 258. and a skeleton information column 
259. The Implementation Identifier is a name for the 
implementation that is supplied by the developer when 
an implementation definition is created. The Subcon- 
tract Meta Object is a location indicator from a particular 
implementation definition to a Subcontract Meta Object 
contained in the subcontract registry 200. The Interface 
Identifier is a fixed globally unique name of the type of a 
particular interface. The Ready Flag will be set for a par- 
ticular implementation definition when the implementa- 
tion has been prepared as will be described below with 
reference to Figure 8. If the Ready Flag is not set, then 
the dispatch function may have to wait temporarily until 
the implementation is ready, as described below with 
reference to Figures 12a and 12b, and specifically in 
step 727 of Figure 12b. The skeleton information pro- 
vides information and functions for use by the skeleton 
associated with this implementation. The call back func- 
tions are a set of functions associated with each imple- 
mentation. A wide variety of call back functions may be 
associated with a particular implementation. By way of 
example, the call back functions Lookup. Post InvdRe. 
Revoke, Deactivate and Shutdown will be illustrated. 

The Lookup function takes as an argument a User 
Key and returns a location indicator to a servant, which 
may be NULL if no corresponding object exists. If the 
object is found the invocation continues. If not, an 
exception is returned to the client. The User Key is ref- 
erence data supplied by the developer and may be any 
arbitrary data. The User Key forms part of the object ref- 
erence as will be explained below with reference to Fig- 
ure 5. The Post Invoke function takes as an argument a 
user key and returns no value. It may execute various 
operations that the developer wishes to perform after 
the invocation of an object. The Revoke function takes 
as an argument the User Key and performs the function 
of preventing an object from being referred to. The 
Deactivate function takes as arguments the User Key 
and a deactivate closure. The deactivate closure is a 
procedure that enables the ORB to do some internal 
clean up once the object has been deactivated by the 
body of the deactivate function. Essentially, the deacti- 
vate function itself serves to make the object inaccessi- 
ble. The Shutdown function is used to shutdown a 
particular implementation definition by removing all 
servant objects if necessary. Each set of call back func- 
tions 258 associated with an implementation definition 
may be represented in an object that contains these 
functions. 

Referring again to Figure 3. shown in particular in 
the implementation registry 250 is an implementation 
definition 262. This definition is for a PRINTER imple- 
mentation of the interface PRINTER INTERFACE and it 
has a location indicator 266 to Subcontract 1 of the sub- 
contract registry. It also has five unique call back func- 
tions, and a unique skeleton dispatch function. Also 
shown is an implementation definition 264 for a 
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Figure 6 will be described in more detail. The create 
implementation^ initior) function takes as arguments a 
quality of service list, a name for an implementation and 
an Interface Identifier. In step 452 the desired quality of 
service list is used to search through the subcontract 5 
registry and match the quality of service list of an exist- 
ing Subcontract Meta Object. This step may be per- 
formed by searching each entry in the subcontract 
registry using the subcontract registry functions as dis- 
cussed above. In step 454 an entry is created in the H 
implementation registry using the Interface Identifier 
and the name for the implementation as the Implemen- 
tation Identifier. In step 456 the Subcontract Meta 
Object field for this new entry is updated to point to the 
identified Subcontract Meta Object found in step 452. 15 
Next, in step 457 all skeleton information is stored in this 
new entry, including the skeleton dispatch function 
unique for this implementation definition. After this step 
this new implementation definition is returned and this 
function is done and control returns to step 404 of Fig- 20 
ure 6. 

Referring next to Figure 8, a prepare implementa- 
tion definition function suitable for implementing step 
404 in Figure 6 will be described in more detail. This 
function takes as arguments an implementation defini- 25 
tion and a set of associated call back functions. In step 
484 the implementation definition is used to determine 
the corresponding Implementation Identifier. Next, in 
step 486 these call back functions are inserted in the 
implementation registry at the entry corresponding to 30 
the found Implementation Identifier. In step 488 the 
implementation Ready Flag is set to YES to indicate 
that this implementation is now ready for use. Because 
the implementation is now ready, in step 490 any wait- 
ing procedures are now unblocked and may use this 35 
implementation. For example, step 727 of the invocation 
procedure of Figure 12b must wait until the implementa- 
tion is ready. After this step 490 the function is done and 
control returns to step 406 of Figure 6. 

Referring next to Figure 9, a create object reference 40 
function suitable for implementing step 406 in Figure 6 
will be described in more detail. This function takes as 
arguments an implementation definition and a User Key. 
It will eventually create and return an object reference 
by using the subcontract client representation create 45 
function described below. In step 502 the implementa- 
tion definition is used to reference its corresponding 
entry in the implementation registry in order to produce 
the corresponding Subcontract Meta Object location 
indicator that points to the appropriate Subcontract so 
Meta Object in the subcontract registry. In step 504 the 
subcontract client representation create function corre- 
sponding to the entry in the table for this found Subcon- 
tract Meta Object is returned. In step 506 this 
subcontract client representation create function is ss 
called with the User Key and the received implementa- 
tion definition as arguments. This client representation 
create function creates an object reference for a servant 



(that may or may not yet exist) corresponding to the 
Interface Identifier and named Implementation Identifier 
of the received implementation definition. Because this 
client representation create function is unique to each 
subcontract, this step utilizes the appropriate features of 
the corresponding subcontract in order to return the 
object reference. In step 508 this object reference cre- 
ated is returned and the function is done and control 
returns to step 408 of Figure 6. 

Referring next to Figure 10, a deactivate implemen- 
tation function suitable for implementing step 412 in Fig- 
ure 6 will be described in more detail. This function take 
as an argument an implementation definition. In step 
520 the implementation definition is used to produce the 
corresponding Implementation Identifier. In step 522 the 
entry in the implementation registry corresponding to ^ 
this Implementation Identifier is removed. This removal 
effectively prevents this implementation of an interface 
from being used because the implementation is no 
longer present in the implementation registry. After this 
step the function is done and control returns to the end 
of Figure 6. 

Referring next to Figure 11, a shut down function 
suitable for implementing step 416 in Figure 6 will be 
described in more detail. This shutdown function is used 
to shutdown all implementation of objects within the 
ORB. Step 540 introduces a looping structure that will 
step through all entries in the implementation registry. 
An index J is first set equal to the first entry in the imple- 
mentation registry. Upon each iteration of this loop, the 
index J will be set to the next entry in the table. Step 540 
also tests whether the last entry has been processed, if 
so. then this function is done. In step 542 the shutdown 
call back function corresponding to a particular imple- 
mentation definition at entry J is called in order to shut- 
down this particular implementation. Once all 
implementations have been shutdown, then the ORB 
may safely cease processing. After this step the func- 
tion is done and control returns to the end of Figure 6. 
Now that an embodiment of the create object reference 
function of Figure 6 has been described, the dispatch 
function will be described. 

Figures 12a. 12b and 13 illustrate an embodiment 
of a procedure for performing object invocation. This 
procedure makes use of the implementation and sub- 
contract registries in order to take advantage of subcon- 
tracts in accordance with one of the goals of the present 
invention. Object invocation is the process by which a 
client invokes an operation or accesses an attribute of a 
server object, a call is made through the ORB to the 
server object, the operation is invoked upon the server 
, object, and a result is returned to the client (if required). 
Once the mechanisms on the client side have proc- 
essed this request and passed the request to the client 
transport layer, the client transport layer sends the 
request to the server s transport layer. Figures 12a. 12b 
and 13 describe how the transport layer calls a particu- 
lar dispatch function of a subcontract in order to invoke 
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the server object. Each subcontract has a unique dis- 
patch function that performs, the steps that will be 
described below! The procedure will use the implemen- 
tation registry in order to find the appropriate lookup 
function and the appropriate skeleton dispatch function s 
for that implementation. The subcontract registry will 
also be used to provide a bad server identifier handler 
funct.cn corresponding to a particular subcontract if 
necessary. 

Figure 12a begins by having the transport layer call w 
he dispatch function for a particular subcontract using 
the subcontract identifier. Due to the clients invocation 
on the object reference, the transport layer has been 
provided with a marshal buffer that contains among 
other information, the object key for the server object rs 
This object key contains information as shown in Figure 
5. The marshal buffer also contains the name of the 
method to be invoked upon the server object and any 
necessary arguments. As the subcontract identifier is 
contained within the object key as shown in Figure 5 so 
the transport layer is able to "peek" at this subcontract 
-dentrf.er in order to determine which subcontract is 
appropriate and which dispatch function should be 
called. 

In step 702 this subcontract identifier is extracted ss 
from the object reference in the marshal buffer The 
process of extraction means that this information is 
taken from the marshal buffer and is no longer present 
<n the marshal buffer. Next, in step 704 this extracted 
subcontract identifier is compared with the current sub- 30 
contract that is being utilized in order to verify that the 
appropriate subcontract is being used. As described 
above during object development, an application devel- 
oper has associated a particular subcontract with an 
object by using a subcontract identifier. 3S 

In step 706 the server identifier is extracted from 
the object reference in the marshal buffer. The server 
object that is the subject of the invocation is present 
within a particular server process on a host computer 
thus rt is .mportant to verify that this server identifier 40 
matches with the identifier of the current server. In step 
708 this extracted server, identifier is compared with the 
identifier of the current server in order to determine if 
the object reference is referencing the appropriate 
server process. Step 710 determines if the extracted 45 
server identifier is valid and does match with the current 
server, ff not. this indicates that the server identifier is 
invalid and appropriate action should be taken This 
action may be performed by a bad server identifier han- 
dler function. Step 71 2 determines if an appropriate bad so 
server identifier handler is registered in the subcontract 
meta object. Because the subcontract identifier has 
already been extracted from the object reference this 
step may be performed by using the subcontract regis- 
try of Figure 2. The subcontract identifier acts as a key 55 
to a particular row of this table that allows a search of 
column 208 in order to determine if the bad server iden- 
tifier handler is present. If the handler is not present 



then the system throws an exception relating to this sit- 
uation ,n step 716 and the dispatch function ends. If. 

mtrH^ e H, a,Kj,er iS r69istered in *• subcontract 
meta object, then ,n step 714 this bad server identifier 

ESTi n?* *• subc °n*act identtfier and the 

Jf^ 38 ar9uments Af ter this step, the dis- 
patch function ends. 

Returning now to step 710. if the extracted server 
KlenMier does match with the current server, then con- 
frd moves to step 718. In step 718 the implementation 
■dentofier is extracted from the object reference in the 
marshal buffer. In step 720 this extracted implementa- 
tion identifier is used as a key to the implementation 
registry of Figure 3 in order to find the appropriate 
implementation definition. The use of the implementa- 
tion registry is explained above with reference to Figure 
I Jh'S step 720 may be performed by searching 
through column 252 of the implementation registry of 
Figure 3 in order to determine if the implementation 
identifier is present in the table. If in step 722 it is deter- 
mined that the implementation definition is not found 
then m step 724 an exception is thrown relating to this 
condition and the dispatch function ends. If however the 
implementation definition is found then the operation 
may proceed with use of the definition. 

However, even if an implementation definition is 
found, rt may not necessarily be ready for use. An imple- 
mentation definition is ready, or prepared, if the prepare 
implementation definition step 404 of Figure 6 has been 
executed. Once this step has been executed, the Ready 
Rag will be set. Step 726 tests whether this Ready Flag 
has been set. ff not. then in step 727 the dispatch func- 
tion enters a wait state in which it waits for the imple- 
mentation definition to become ready. Once the 
implementation definition is ready then control moves 
from step 726 to step 728. In step 728 the lookup func- 
tion from the implementation definition is extracted This 
lookup function is one of the call back functions of col- 
umn 258 of Figure 3 and will be used to produce a local 
location indicator to the servant. In step 730 the User 
Key is extracted from the object reference in the mar- 
shal buffer. Next, in step 732 the lookup function is 
called with the User Key as an argument. Once this 
function has executed it will return a location indicator to 
the servant. This location indicator may be implemented 
m the local language of the server. By way of example 
this location indicator may be a C++ object pointer that 
references the servant C++ object. 

Now that a local location indicator has been 
obtained to the servant object the dispatch function is 
ready to execute the appropriate method upon the serv- 
ant object that was originally requested by the client In 
step 733 the method descriptor is extracted from the 
marshal buffer. The method descriptor is a representa- 
tion from the clients point of view of that particular 
method name defined upon the servant that the dient 
wishes to invoke. In step 734 the skeleton dispatch 
functon is extracted from the implementation definition 
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This skeleton dispatch function may be found in the 
implementation registry- in column 259 of Figure 3. In 
step 736 this skeleton dispatch function is called with 
the arguments servant location indicator, marshal buffer 
and the method descriptor. This function will be 
explained in more detail below with reference to Figure 
1 3. The skeleton dispatch function achieves the result of 
executing the method upon the servant that the client 
requested be performed. Once this operation has taken 
place the invocation of the server object by the client 
has finished. However, an additional function may be 
executed. The post invoke function is a developer 
defined function for each implementation that achieves 
a functionality that the developer wishes. In step 738 
this post invoke function is extracted from the implemen- 
tation definition. In step 740 this post invoke function is 
called with the User Key as an argument. The post 
invoke function may be used by the developer to per- 
form a particular action after the invocation of an object. 
For example, Lookup/ Post-Invoke may count the 
number of active invocations on a particular server. This 
is useful for managing the life cycle of servant objects. 

Referring next to Figure 13, a skeleton dispatch 
function suitable for implementing step 736 in Figure 
12b will be described in more detail. This function first 
begins in step 802 in which an unmarshaling mecha- 
nism is selected based upon the method descriptor. The 
unmarshaling mechanism may be a sequence of code 
that is selected by a switch statement for example. As 
other information has already been extracted from the 
marshal buffer, the only information remaining in the 
marshal buffer at this point are the arguments of the 
method to be called. In step 804 the selected unmar- 
shaling mechanism is used to unmarshal the remainder 
of the marshal buffer into the invocation arguments. In 
step 806 the method descriptor is used to invoke the 
method defined upon the servant using the invocation 
arguments. This step has the effect of executing the 
method that was originally requested by the client. It is 
possible that this method returns no value at all and per- 
forms other functions, or may be that the method 
returns a value to the client Step 808 determines if the 
method produces a reply. If not, then this function is 
done. If so, then control moves to step 810. In step 810 
an appropriate marshalling mechanism is selected cor- 
responding to the method descriptor. In step 812 the 
selected marshalling mechanism is used to marshal the 
reply into the marshal buffer. At this point the marshal 
buffer is ready to be returned through the transport layer 
to the client. After this step, this function is done and 
control returns to step 738 of Figure 12b. 

The present invention as described above employs 
various process steps involving data stored in computer 
systems. These steps are those requiring physical 
manipulation of physical quantities. Usually, though not 
necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, trans- 
ferred, combined, compared, and otherwise manipu- 



lated. It is sometimes convenient, principally for reasons 
of common usage, to refer to these signals as bits, val- 
ues, elements, variables, characters, data structures, or 
the like. It should be remembered, however, that all of 

5 these and similar terms are to be associated with the 
appropriate physical quantities and are merely conven- 
ient labels applied to these quantities. 

Further, the manipulations performed are often 
referred to in terms such as identifying, running, or com- 

w paring. In any of the operations described herein that 
form part of the present invention these operations are 
machine operations. Useful machines for performing 
the operations of the present invention include general 
purpose digital computers or other similar devices. In all 

is cases, there should be borne in mind the distinction 
between the method of operations in operating a com- 
puter and the method of computation itself. The present 
invention relates to method steps for operating a com- 
puter in processing electrical or other physical signals to 

20 generate other desired physical signals. 

The present invention also relates to an apparatus 
for performing these operations. This apparatus may be 
specially constructed for the required purposes, or* it 
may be a general purpose computer selectively acti- 
os vated or reconfigured by a computer program stored in 
the computer. The processes presented herein are not 
inherently related to any particular computer or other 
apparatus. In particular, various general purpose 
machines may be used with programs written in accord- 

30 ance with the teachings herein, or it may be more con- 
venient to construct a more specialized apparatus to 
perform the required method steps. The required struc- 
ture for a variety of these machines will appear from the 
description given above. 

35 In addition, the present invention further relates to 
computer readable media that include program instruc- 
tions for performing various computer-implemented 
operations. The media and program instructions may be 
those specially designed and constructed for the pur- 

40 poses of the present invention, or they may be of the 
kind well known and available to those having skill in the 
computer software arts. Examples of computer reada- 
ble media include, but are not limited to, magnetic 
media such as hard disks, floppy disks, and magnetic 

45 tape; optical media such as CD-ROM disks; magneto- 
optical media such as floptical disks; and hardware 
devices that are specially configured to store and per- 
form program instructions, such as read-only memory 
devices (ROM) and random access memory (RAM). 

so Examples of program instructions include both machine 
code, such as produced by a compiler, and files contain- 
ing higher level code that may be executed by the com- 
puter using an interpreter. 

Figure 14 illustrates a typical computer system in 

55 accordance with an embodiment of the present inven- 
tion. The computer system 100 includes any number of 
processors 102 (also referred to as central processing 
units, or CPUs) that are coupled to storage devices 
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temprc^idingap,^^^^^^ sys- 

'"9 the implementattons oTs^! for use in ^k- 
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tions, each implementation definition including an 
implementation identifier -and a subcontract location 
indicator that indicates a unique subcontract entry 
in the feature registry, wherein the method further 
comprises the step of creating an implementation 
definition for the implementation of the server 
object to be created. . 

A computer-implemented method of invoking an 
object method defined on a distributed server 
object within a distributed object computing system, 
the distributed object computing system utilizing an 
implementation registry including a plurality of 
implementation definitions, each implementation 
definition defining an implementation for an inter- 
face within the distributed object computing system, 
each implementation definition having an imple- 
mentation identifier and associated functions, the 
method comprising the steps of: 

receiving a marshal buffer containing an object 
reference to the server object; 

extracting an implementation identifier from the 
object reference in the marshal buffer; 

determining an implementation definition within 
the implementation registry by using the 
extracted implementation identifier as a key; 

calling a lookup function of the implementation 
def inition in order to produce a location indica- 
tor to the server object; and 

calling a skeleton dispatch function of the 
implementation definition in order to invoke the 
object method def ined on the server object. 

6. A method as recited in claim 5 further comprising 

* 40 

the steps of : 

extracting a subcontract identifier from the 
object reference in the marshal buffer; and 

verifying that the extracted subcontract identi- 45 
f ier matches a current subcontract. 
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dler function that is identified in a subcontract 
registry. 
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7. A method as recited in claim 5 further comprising 
the steps of: 

extracting a server identifier from the object ref- 
erence in the marshal buffer; 
determining if the extracted server identifier 
matches a current server; and 

wherein when it is determined that the 
extracted server identifier does not match a 
current server the method further comprises 
the step of calling a bad server identifier han- 



A method as recited in claim 5 wherein the step of 
calling a lookup function includes the sub-steps of: 

extracting the lookup function from the deter- 
mined implementation definition; and 

extracting a user key from the object reference 
in the marshal buffer. 

A method as recited in claim 5 wherein the step of 
calling a skeleton dispatch function includes the 
sub-steps of: 

extracting the skeleton dispatch function from 
the determined implementation definition; and 

extracting a method descriptor from the object 
reference in the marshal buffer. 

10 A feature registry data structure embodied ima 
computer-readable medium, the feature registry 
used for invoking implementations of server objects 
within a distributed object computing system, the 
distributed object computing system providing 'a 
plurality of features for use in the implementation of 
server objects, the feature registry including a plu- 
rality of subcontract entries, each subcontract entry 
comprising: 

an implementation identifier naming an imple- 
mentation of an associated server object; 

an interface identifier naming an interface of 
the associated server object that defines oper- 
ations for the associated server object; 

at least one feature identifier, the feature identi- 
fier identifying one of the plurality of features 
that are provided by the distributed object com- 
puting system; and 

a create function for creating an object refer- 
ence for the associated server object in a man- 
ner that utilizes the feature identified by the 
feature identifier within a context that is appro- 
priate in view of the feature identifier. 

1 1 A feature registry data structure as recited in claim 
10 wherein each feature identifier includes a feature 
name-value pair, wherein each feature name-value 
pair includes: 

a feature name that identifies an associated 
one of the plurality of features; and 
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a value that further qualifies the associated tea- 

1 2- A subcontract registry data structure embodied in a 

Ik- ^ ^ 6at " 19 0b,ect references for server 

diStribUted ° bject "> Wng s^ 6 
tern, the distnbuted object computing system 21 
viding , a plurality of features for SI in fhTc^on 

trlr?' <2 f r6nCeS f ° r S6rVer *■«*■ subcon 

^ £ ,ndUdin9 3 p,ura,i * * subconSt 
objects, each subcontract object comprising 

Zi^S"? klmi,ler subcon- 
tract object to which it corresponds; , 5 

S^SZ- ,eature 016 feature iden «- 

.er -dent.fy.ng one of the plurality of features 
that are provided by the distributed object com 
puting system; and 

suteont^^ 0 " aSSOdated ^quely with each 
? ° b,eCt - create ^^ion used to 
create and return an object reference for a 

M.ed by the feature identifiers associated with 
each subcontract object. 
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13. A subcontract registry data structure as recited in 

wherem each feature name-value pair includes^' 

a feature name that identifies an associated 
one of the plurality of features; and 

J^ue that further qualifies the associated fea- 

clam 12 wherem each subcontract object furthe? 
2T!f; b8d M0 * r ^^ation handler fuS 

EZFJ*™ * 18 determined *« 8 fcJS- 

Nation of a particular object reference does not 
match with a server process. 

15. An implementation registry data structure embed- 
ed ,n a computer-readable medium, the imp.emen- 
tation reg,stry used for registering a 2^ 
■mplernentation definitions, each UlemenSion 
def^ton defining an 

? L <,istributed object computing system 
EnS^?*" C ° mpU,in9 S ^ Proving Ta 
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a l^ P,6 I!l entati0n identi,ier that «entifies a 
corresponding implementation definition; 
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US^HS^ ,0 a Contract object 
assoaated wrth the implementation definition 

assSaSlST^'^ * enWyin9 tne ^erface 
assoaated with the imp«ementation definition 

a set of functions associated with the imole- 
K*" de,initi °" «« ^ creating a^d 
-nvokmg a server object that uses- the imol* 
mentation definition. ^ fr 

16 ' SsST?^ r69iStry data as 
associated with the implementation definition 
•nclude a skeleton dispatch function used £ To° 
•no a requested method on the server SjZ. 

1 7. A computer apparatus for use in invoking an imole 
mentation of a server object within SSnSS 

skst* 8 system - the computer ~ 



a processing unit; ^ 
. a ng tSf 0 ^ d6ViCe C ° Up,ed to 106 P^ss- 

a storage device in communication with the 
processing unit, the storage device including a 
feature registry data structure used for invoking 

ZEST?" of server witnin tta 

SE? h ,6Ct C ° mPUtin9 System - *s 
Waited object computing system providing a 

Son * t fea,Ur k fof USe in ,he i^P'emSa 
6rVer ° bjeCts - fea ^e registry 
mduding a plurality of subcontract erE 

each subcontract entry including. 

m'lrZ' em ! ( n,a,i0n * denti,ier nami "9 an imple- 
mentation of an associated server object. 

an interface identifier naming an interface of 

ItionsTSf S6rVer °° iect *« defin *s W 
ations for the associated server object. 

SUU^ f6atUre id6nti,ier - 4,16 fea,u ^ identi- 
-er ^ identifying one of the plurality of features 
that are provided by the distributed object com- 
putmg system, and 

n~ t£ the , assoc,ated ^rver object in a man- 
ner that utilizes the feature identified by the 
feature .dentifier within a context that is appro- 
priate in view of the feature identifier. 

18. A computer program product comprising a compu- 
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ter-usabie medium having- computer-readable code 
embodied thereOn ter creating an object reference 
for a distributed server object within a distributed 
object computing system, the distributed object 
computing system utilizing a feature registry for 
invoking implementations of server objects, and the 
distributed object computing system providing a 
plurality of features for use in invoking the imple- 
mentations of server objects, the computer pro- 
gram product comprising computer-readable 
program code for effecting the following steps within 
the computer system: 

receiving a request that an object reference be 
created for a server object; 

identifying a subcontract entry in the feature 
registry, the feature registry including a plurality 
of subcontract entries each associated with a 
feature set including at least one of the plurality 
of features, the subcontract entry being associ- 
ated with the server object reference to be cre- 
ated and being arranged to identify a feature 
set having at least one feature to be utilized in 
invoking an implementation of the server 25 
object; 

identifying a create function associated with the 
identified subcontract entry, the create function 
being responsible for creating the server object 
using the feature set identified by the identified 
subcontract entry; 

invoking the create function in order to produce 
an object reference for the server object; and 

returning the produced object reference. 



tation definitions; each implementation definition 
including an implementation identifier and a sub- 
contract location indicator that indicates a unique 
subcontract entry in the feature registry, wherein 
5 the computer program product further comprises 

program code for creating an implementation defini- 
tion for the implementation of the server object to 
be created. 

w 22. A computer program product comprising a compu- 
ter-usable medium having computer-readable code 
embodied thereon for invoking an object method 
defined on a distributed server object within a dis- 
tributed object computing system, the distributed 
is object computing system utilizing an implementa- 
tion registry including a plurality of implementation 
definitions, each implementation definition defining 
an implementation for an interface within the distrib- 
uted object computing system, each implementa- 
20 tion definition having an implementation identifier 
and associated functions, the computer program 
product comprising computer-readable program 
code for effecting the following steps within fhe 
computer system: 
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1.9. A computer program product as recited in claim 18 
wherein each feature set includes at least one fea- 
ture name-value pair, wherein each feature name- 
value pair includes: 

a feature name that identifies an associated 
one of the plurality of features; and 

a value that further qualifies the associated fea- 
ture. 

20. A computer program product as recited in claim 1 8 
wherein the step of invoking the identified create 
function includes passing a user-identified key to 
the create function. 

21. A computer program product as recited in claim 18 
wherein the distributed object computing system 
also utilizes an implementation registry, the imple- 
mentation registry including a plurality of implemen- 
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receiving a marshal buffer containing an object 
reference to the server object; 

extracting an implementation identifier from the 
object reference in the marshal buffer; 

determining an implementation definition within 
the implementation registry by using the 
extracted implementation identifier as a key; 

calling a lookup function of the implementation 
definition in order to produce a location indica- 
tor to the server object; and 

calling a skeleton dispatch function of the 
implementation definition in order to invoke the 
object method defined on the server object. 

23. A computer program product as recited in claim 22 
further comprising program code for effecting the 
steps of: 

extracting a subcontract identifier from the 
object reference in the marshal buffer; and 

verifying that the extracted subcontract identi- 
fier matches a current subcontract. 

24. A computer program product as recited in claim 22 
further comprising program code for effecting the 
steps of: 

extracting a server identif ier from the object ref- 
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